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Die Erfindung bezieht sich auf ein ProzeBsteuersy- 
stem mit einer Reihe von Teilnehmern, die jeweils Hard- 
ware-Zeitgeber enthalten und durch Bussysteme mit- 
einander verbunden sind, uber die Informationen nach 
vorgegebenen Schnittstellenprozeduren ubertragen 
werden, mit denen Interrupts in den Teilnehmern aus- 
losbar sind. 

Es ist bereits ein Absolutzeit-Obertragungssystem 
bekannt bei dem von einer Hauptuhr Zeitangaben 
drahtgebunden an nachgeordnete Einrichtungen, wie 
z. B. Nebenuhren und Zeitregistriergerate, ubertragen 
werden (nachrichten elektronik 7-1979, S. 233, 234). Die 
Nebenuhren und Zeitregistriergerate werden bei die- 
sem Absolutzeit-Obertragungssystem unmittelbar 
durch Zeittakte gesteuert, die in Form eines seriellen 
Impulstelegramms ubertragen und von den zeitanzei- 
genden und zeitregistrierenden Einrichtungen erkannt 
und in eine Zeitanzeige umgewandelt werden. 

Bekannt ist auch ein Steuernetz fur Zeitanzeigegera- 
te, bei dem zeitkennzeichnende Signale leitungsgebun- 
den iiber ein beliebig organisiertes Leitungsnetz zu An- 
zeigegeraten ubertragen werden. Die zeitkennzeich- 
nenden Signale werden digital iiber eine beliebige Mo- 
dulationsart einem hoherfrequeriten Trager aufgepragt 
(DE-OS 21 39 077). 

In einem ProzeBsteuersystem mit einer Reihe von 
Teilnehmern, die jeweils ProzeBgroBen messen, iiber- 
wachen, steuern oder regeln. ist es ofters notwendig, fur 
bestimmte Ereignisse des Prozesses die Zeit des Auftre- 
tens zu kennen bzw. bestimmte Ereignisse zu festgeleg- 
ten Zeiten auszuldsen. Es muB daher in Funktionseinhei- 
ten des ProzeBsteuersystems (insbesondere den prozeB- 
nahen Einheiten) moglich sein, die Ereignisse mit einer 
allgemein giiltigen Echtzeit in Beziehung zu bringen. 
Diese Teilnehmer bzw. Funktionseinheiten bendtigen 
deshalb einen direkten Zugriff auf eine Echtzeituhr, die 
zugleich das Datum angibt. 

Der Erfindung liegt die Aufgabe zugrunde, ein Pro- 
zeBsteuersystem der eingangs beschriebenen Gattung 
dahingehend weiterzuentwickeln, daB die Teilnehmer 
des ProzeBsteuersystems ohne Erhdhung des Leitungs- 
aufwands fur die Informationsiibertragung zwischen 
den Teilnehmern unter weitgehender Nutzung der oh- 
nehin fur andere Zwecke erforderlichen Hardware be- 
darfsweise iiber die Echtzeit verfiigen. 

Die Aufgabe wird erfindungsgemaB dadurch gelost, 
daB in einem Teilnehmer eines Busses fur die Echtzeit 
eine Zentraluhr vorgesehen ist, daB in den anderen Bus- 
teilnehmern gegebenenfalls Echtzeituhren vorgesehen 
sind, die jeweils eine von einem Prozessor gefiihrte Soft- 
ware-Uhr enthalten, deren Weiterschaltung vom Pro- 
zessor durch Zugriff auf einen Hardware-Zeitgeber vor- 
genommen wird, und daB zur Synchronisierung der Uh- 
ren dieser Teilnehmer eine Synchronisationsprozedur 
vorgesehen ist, durch die jeweils die Echtzeit der Zen- 
traluhr festgehalten und in einem definierten Zeitab- 
stand hierzu in wenigstens einem Teilnehmer ein Inter- 
rupt ausgelost wird, durch dessen Auftreten die im Teil- 
nehmer vorhandene Echtzeit ebenfalls festgehalten und 
mit der vom Echtzeitverteiler in das Datenf rmat der 
Schnittstelle umgesetzten und zum Teilnehmer iibertra- 
genen Echtzeit der Zentraluhr zum Nachstellen der 
Echtzeituhr im Teilnehmer verwendet wird. 

Die Zentraluhr wird z. B. mit der amtlichen Zeit ein- 
gestellt und synchronisiert. Die Zentraluhr kann durch 
eine Funkuhr realisiert sein. Es ist zweckmaBig, die 



Echtzeit in dem oder den Teilnehmern unter Ausnut- 
zung vorhandener Taktgeber und gegebenenfalls Zahl- 
bausteinen in Verbindung mit Software bereitzustellen. 
Auf diese Weise konnen alle Teilnehmer bzw. Funk- 
5 tionseinheiten, die die Echtzeit benotigen, eine Echtzeit- 
uhr fiihren. Beispielsweise werden alle zu einer Station 
einer Energieverteilungsanlage gehorenden Echtzeituh- 
ren von der zentralen Echtzeituhr gestellt und synchro- 
nisiert Die Wirkungsrichtung entspricht hierbei vor- 
io zugsweise der Hierarchie von Datenbussystemen zwi- 
schen den Teilnehmern. 

Die Echtzeit wird bereitgestellt, indem die Echtzeit- 
uhren in den Teilnehmern gefiihrt werden, deren Echt- 
zeit iiber Bussysteme verteilt wird, wobei unter Vertei- 
15 lung die Obertragung der Echtzeit zu den Teilnehmern 
und die Synchronisation der Echtzeituhren in den Teil- 
nehmern zu verstehen ist Die Zentraluhr ist vorzugs- 
weise mit dem Echtzeitaufbereiter zu einer Echtzeitzen- 
trale kombiniert die. insbesondere in einer Baueinheit 
2o realisiert ist 

Die Zentraluhr liefert die Echtzeit normalerweise in 
vorgegebenem Datenformat und vorzugsweise einen 
Sekundentakt zur Synchronisation an einen zentralen 
Echtzeitaufbereiter. Dieser setzt die Echtzeitcodierung 
25 in ein fur die gesamte Echtzeitbereitstellung giiltiges 
Format urn. Von hier aus wird die Echtzeit iiber die 
vorhandenen Datenschnittstellen zu den einzelnen 
Echtzeituhren ubertragen. Die Synchronisation der 
Echtzeituhren erfolgt zweckmafligerweise iiber ohne- 
30 hin vorhandene oder notwendige Hardware-Schnitt- 
stellen, z. B. Datenschnittstellen, Bussysteme und dgL, 
iiber die auch andere Informationen zwischen den Teil- 
nehmern ilbertragen werden. Es ist aber auch moglich, 
die Synchronisation iiber einen separaten Sekundentakt 
35 mit zusatzlicher Hardware zu erzeugen. Dieser Sekun- 
dentakt wird dann zentral generiert. Liefert in diesem 
Fall nicht schon die Zentraluhr einen fur das System 
geeigneten Sekundentakt, d. h. einen Sekundentakt mit 
der erforderlichen Zeitgenauigkeit, dem richtigen Pegel, 
40 der Valenz und dem fan out usw, dann wird dieser im 
zentralen Echtzeitaufbereiter generiert Beide Synchro- 
nisationsverfahren konnen auch nebeneinander, d. h. ge- 
mischt, eingesetzt werden. 
Bei der Realisierung der einzelnen Software-Funktio- 
45 nen miissen die Wirkungen von Unterbrechungen (In- 
terrupts, DMA-Zugriffe) und Oberlappungen (Zugriffe 
auf Dual- Port- Ram) besonders beachtet werden. 

Mit der Erfindung wird eine Echtzeituhr zur Verfu- 
gung gestellt, die mit iiblicherweise in Funktionsbaustei- 
50 nen fiir ProzeBsteuerungen vorhandenen Hardware- 
komponenten auskommt 

Jede Echtzeituhr besteht aus der Kombination eines 
Hardware-Zeitgebers und einer Software-Uhr. Beide 
zusammen bilden eine Echtzeituhr, die bei Ausfall der 
55 Synchronisierung frei weiterlauft 

In Abhangigkeit von den Hardwaregegebenheiten 
der Funktionsbausteine und den Softwareanforderun- 
gen konnen zwei verschiedene Arten von Echtzeituhren 
realisiert werden: 
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— Eine Echtzeituhr mit einem asynchronem Hard- 
ware-Zeitgeber. Diese Uhr kann normalerweise 
mit der vorhandenen Hardware realisiert werden 
und wird bevorzugt eingesetzt 

— Eine Echtzeituhr mit synchronem Hardware- 
Zeitgeber. Diese Uhr kann einen Zeitscheiben-In- 
terrupt generieren. Sie sollte nur dann realisiert 
werden, wenn das Softwaresystem uhbedingt einen 
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Zeitscheiben-Interrupt erfordert, da hier hdhere 
Anforderungen an die Hardware (Zeitgeber) ee- 
stellt werden mQssen. 

Die Echtzeituhr mit einem asynchronen Hardware- 
Zeitgeber ist normalerweise auf alien Baueinheiten rea- 

hsierbar, da sie keine besonderen Anforderungen an den 

Hardware-Zeitgeber stellt. Wenn die durch den jeweili- 

gen ProzeD gegebenen Bedingungen es zulassen, alle 

Echtzeituhren mit asynchronem Hardware-Zeitgeber 

zu betreiben, dann reicht ein einziges Grundkonzept fur 

samtliche Echtzeituhren aus. 
Der Hardware-Zeitgeber ist insbesondere ein binarer 

Zahlerbaustem, auf den der Prozessor, der die Software- 
Uhr fuhrt lesend zugreifen kann. Er wird dauernd mit 
einem quarzstabilen Takt fast beliebiger Frequenz ver- 
sorgt und zahlt ohne Unterbrechuhg zyklisch die Takt- 
unpulse Die Bezeichnung "asynchron" bedeutet hier, 

in ke, ! ne m ah ^ ngangS » fr t qU ! ,1 f " nd Zm ^V k ^ «ne rausenschleile durchla 
ZeitViEen ^^f ^,^1 irendwelchen *> grammlaufzeit beansprucht 
^eiteinheiten der Software-Uhr stehen mussen. Diese ~ ■ - - • - 

Zahlerbetnebsart ist die einfachste iiberhaupt und wird 
von alien Hardware-Zeitgebem beherrschL 

Der Hardware-Zeitgeber ist wenigstens ein aus einer 
raktquelle gespeister, frei laufender Dualteiler Bei- 
spielsweise ist der Hardware-Zeitgeber ein einfacher 
Dualteiler (Binarteiler), der in 
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Verfahren zum Einsatz kommt: Der Prozessor, der die 
Software-Uhr fuhrt, kann den Hardware-Zeitgeber di- 
rekt lesen. 

Zur Uhrzeitfuhrung wird zunachst der Hardwar - 
; Zeitgeber eingelesen. 

Dann wird ermittelt, wieviel Zeit seit der letzten Ak- 
tuahsierung der Software-Uhr vergangen ist Hierzu 
wird der Stand des Hardware-Zeitgebers, der zur letz- 
ten aktuellen Software-Uhrzeit gehort, bereitgehalten. 

Eine Berechnung gibt die Anzahl der Millisekunden 
an, die der Uhrzeit aktuell hinzugerechnet werden mQs- 
sen. Wird eine fortgesetzte Subtraktion (Multiplikation) 
verwendet, dann ist die Programmlaufzeit zur Berech- 
nung der neuen Uhrzeit umso grdBer, je mehr Zeit seit 
der letzten Zeitrechnung vergangen ist 

Aus diesem Grund kann es vorteilhaft sein, die Uhr- 
zeit nicht nur bei Bedarf neu zu berechnen, sondern 
zwischendurch immer dann, wenn das Programmsystem 
eine Pausenschleife durchlauft und ohnehin keine Pro- 



— zyklischem Dauerbetrieb arbeitet und mit einer 

— Eingangsfrequenz > - 10 MHz 
wird, die eine hohe 

— FrequenzstabilitSt, z. B. mit Hilfe eines Quarzes 
aufweist 

Die Mindest-Teilerlange ist abhangig von der Softwa- 
re, da der Prozessor, der die Software-Uhr aus dem 
Hardware-Zeitgeber ableitet alle Zeitgeber-Oberlaufe 
erkennenmuB. 

Die Stellung des Zeitgebers muB durch den Prozessor 
lesbar sein. 

Es ist giinstig, wenn ein Zeitgeber-Oberlauf-Interrupt 
den Prozessor beaufschlagt Durch die Software wird 
vorzugsweise gewahrleistet, daB jeder Zeitgeber-Uber- 
lauf sicher erkannt wird Die Nutzung eines Zeitgeber- 



Zuverlassigkeit der Zeitmessung. 

Die Zahlrichtung kann beliebig sein. Bei einem Ab- 
wartszahler muB der Zahlerstand vor der Weiterverar- 
beitung negiert bzw. invertiert werden. 

Die Software-Uhr wird in den einzelnen Funktions- 
bausteinen jeweils von dem Prozessor bearbeitet, der 
die Uhrzeit benotigt. sei es. urn Ereigniszeiten zu ermit- 
tein Ecntzeitreaktionen zu veranlassen oder auch nur 
um die Uhrzeitsynchronisation an nachgeordnete Uh- 
ren we.terzuleiten. Der Prozessor hat unmittelbaren 
Zugnff auf einen hierfur bereitgestellten Hardware- 
Zeitgeber. 

Die Uhrzeit wird jeweils bei Bedarf und in Pausenzei- 
ten (wenn sonst keine Prozessorleistung verlangt wird) 



Dieses Verfahren kann auch dazu dienen, die Ober- 
laufe des Hardware-Zeitgebers zu erfassen und entspre- 
chend zu beriicksichtigea Diese Art der Zeitgeber- 
Uberlauferkennung funktioniert dann, wenn sicherge- 
25 stellt wird, daB zwischen je zwei benachbarten Neube- 
rechnungen der Uhrzeit weniger als eine Zeitgeber-Zv- 
kJuszeit liegt 

Ein sicheres Verfahren zur Erkennung der Zeitgeber- 
u f u. Uberlaufe liefert der Zeitgeber-Oberlauf-Interrupt In 

beaufschlagt 30 der Interrupt-Routine kann entweder ganz normal die 
Uhrzeit berechnet werden oder einfach ein Uberlauf- 
zahler nachgezahlt werden. Dieser ZShler wird dann bei 
einer spater erfolgenden Uhrzeitberechnung bertck- 
sichtigt 

Der Rest der Uhrzeitfuhrung wird durch das ge- 
wunschte Format der Uhrzeit wesentlich mitbestimmt 
und besteht im allgemeinen aus einem mehrstufig n 
Zahler-Aufbau mit Sonderfunktionen. 

Es ist auch moglich. eine Echtzeituhr mit synchronem 
Hardware-Zeitgeber aufzubauen. 

Bei zu steuernden Prozessen in der Energieverteilung 
ist es erforderlich, da3 in den jeweils mit einer Echtzeit- 
uhr ausgestatteten Funktionsbausteinen eine bestimmte 
Zeitdifferenz zwischen zwei Uhren nicht uberschritten 
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,„„ /. ..... — °, ' . -»"•■« 'vim ucrcugenai- 

ten Uhrzeitfuhrung). Die Synchronisation der Uhrzeit 
erlolgt zweckmafligerweise interruptgesteuert 

Die Uhrzeitfuhrung ist verantwortlich fur den "Gang" 
der Echtzeituhr und stellt sicher. daB die aktuelle Echt- 
zeit immer dann mit der geforderten Genauigkeit ver- 
tugbar ist, wenn sie benotigt wird 

Dies wird bei gegebener Hardware mit einem Mini- 
mum an Programmlaufzeit erreicht. indem folgendes 



Die Erfullung dieser Forderung wird bei der Vertei- 
lung der Echtzeit von der Zentraluhr bis zur Echtzeituhr 
im letzten" Funktionsbaustein berucksichtigt. 
Die Verteilung der Echtzeit wird vorzusweise in die 
so beiden Verfahrensschritte "Echtzeitubertragung" und 
Synchronisation der Echtzeituhren" zerlegt 

Obertragung der Echtzeit 

Die Obertragung der Echtzeit erfolgt uber die vor- 
handenen Daten-Schnittstellen, z. B. uber Bussysteme 
vonUhrzuUhr. 

Das Datenformat bei der Obertragung der Echtzeit 
ist an alien Schnittstellen gleich und stellt eine Erweite- 
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ermittelt und vorzugsweise in einem RAM beTeit^ ' an alien Schnittstellen gleich und stellt eine Erweite- 
ten (UhrzeitfOhrunA Die SyncEs^n tfili «° S^n^^ * «t zu- 
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gleich eine Te.lmenge der Darstellung einer kompletten 
Software-Uhr. Das Format ist unabhangig von der Art 
der Synchronisation der Echtzeit-Uhren. 

Eine Ausnahme bei der Echtzeitubertragung gibt es 
be.m Datenformat der Zentraluhr. Dieses Format wird 
von der verwendeten Zentraluhr vorgegeben und im 
zentralen Echtzeitaufbereiter in das Standardformat 
umgesetzt, das bei alien Obertragungsschnittstellen 
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gleich ist 

Die Obertragung zwischen Software-Uhr und Uber- 
tragungs-Schnittstelle erfolgt blockweise, d. h. die ge- 
samte Uhrzeit wird an einem Stuck ubertragen und wird 
gegen gleichzeitige Uhrverstellung verriegelt. 5 

Synchronisation der Echtzeituhren 

Von zentraler Bedeutung fur die gesamte Echtzeitbe- 
reitstellung ist die Art der Synchronisation der Echtzeit- io 
uhren. Hier kommen vorzugsweise zwei Verfahren in 
Betracht, die oben bereits erwahnt wurden: 

— Synchronisation iiber die vorhandenen Schnitt- 
stellen (Bussysteme), 15 

— Synchronisation iiber einen eigenen Takt (sepa- 
rate Taktleitung). 

Das erste Verfahren erforden mehr Softwareauf- 
wand, wahrend das zweite Verfahren mehr Hardware 20 
benotigt. Beide Verfahren konnen auch "gemischt" in 
einer Anlage vorkommen. 

Das erste Verfahren ist wirtschaftljcher. 

Beide Verfahren sind so aufgebaut, daB sie Ausfalle 
von "Synchronimpulsen" tolerieren. 25 

Synchronisation iiber die Datenschnittstellen 

Bei diesem Verfahren wird die Synchronisation iiber 
eine Schnittstellenaktion zwischen Teilnehmern einer 30 
Schnittstelle erreicht Schnittstellen sind hier die Ver- 
bindungen, fiber die auch die Grobuhrzeit ubertragen 
wird. Es wird dabei keine Zusatzhardware benStigt. 

Fur jede Schnittstelle wird eine "Synchronisations- 
prozedur" definiert. Es ist m6glich, fur alle Bus-Schnitt- 35 
stellen (parallel und seriell) ein prinzipielles Konzept zur 
Uhrzeitsynchronisation anzugeben: 

Wichtigstes Prinzip bei der Synchronisation iiber die 
Datenschnittstellen ist die Reduzierung von undefinier- 
ten Verzogerungszeiten auf das erreichbare Minimum. 40 
Dabei muB bedacht werden, dafl bei einer Synchronisa- 
tion iiber mehrere Stufen die Fehler sich addieren. Defi- 
nierte Verzogerungszeiten sind keine Fehlerquellen, da 
sie berucksichtigt werden konnen. 

Das Ziel, mit moglichst geringen undefinierten Verz6- 45 
gerungszeiten (bei der Uhrzeitsynchronisation iiber die 
Datenschnittstellen) zu arbeiten, wird wie folgt erreicht: 

Alle verwendeten Schnittstellen bieten die Moglich- 
keit, durch bestimmte Schnittstellenereignisse (z. B. 
"Dateniibertragung beendet") einen Interrupt zur Ver- 50 
arbeitungseinheit, die die Uhrzeit fuhrt, auszulosen. Dies 
gilt auch fiir die Bus-Controller. 

Es werden Schnittstellenprozeduren angewendet, die 
bei verschiedenen Busteilnehmern (Master, Slave) einen 
Interrupt auslosen. Es hat sich gezeigt, daB der zeitliche 55 
Abstand dieser Interrupte zu einem bestimmten Ereig- 
nis an der Schnittstellen-Hardware auf einige Mikrose- 
kunden genau bestimmbar ist Dadurch wird der zeitli- 
che Abstand von Interrupts, die durch eine Schnittstel- 
lenprozedur bei unterschiedlichen Schnittstellenteilneh- 60 
mern ausgelost werden (z. B. Masters und Slaves), eben- 
falls auf Mikrosekunden genau bestimmt. 

Die Hardware- Voraussetzungen fiir eine ausreichend 
genaue Synchronisierung durch Interrupt sind durch die 
oben erwahnte Feststellung gegeben. Die Software 65 
wird so ausgebildet, daB der anstehende relevante Inter- 
rupt wenigstens einmal innerhalb eines bestimmten 
Zeitintervalls, spatestens nach einer tolerierbaren 



Sperrzeit freigegeben wird. 
Das Verfahren beinhaltet folgende Schritte: 

1. Es wird eine spezielle Bus-Prozedur (Ubertra- 
gung von einem Master bzw. einem ubergeordne- 
ten Busteilnehmer zu einem Slave bzw. einer unter- 
geordneten Einheit) mit einer (zu vereinbarenden) 
Kennung SYNC gestartet. Diese Prozedur kann 
auch ein "Aufruf an alle" sein (soweit vorhanden). 

2. Die SYNC-Busprozedur lost bei alien beteiligten 
Busteilnehmern, auch beim Master, einen Interrupt 
a us. 

3. Die Interrupt-Routinen frieren die augenblickli- 
che Feinzeit in den beteiligten Teilnehmern ein. 

4. 1st ein SYNC-Interrupt in einem Teilnehmer ge- 
sperrt, wenn das SYNC-Ereignis eintritt, dann wird 
dort die Uhrzeit erst nach der Interrupt-Freigabe 
eingefroren und ist mdglicherweise nicht mehr ak- 
tuell (spatere Zeitj. Damit dies erkennbar ist, wird 
auch immer dann, wenn der Interrupt gesperrt 
wird, die aktuelle Uhrzeit eingefroren. Ist der Inter- 
rupt nicht gesperrt, wenn er ausgelost wird, dann 
wird dies erkannt, und beide Zeiten werden gleich- 
gesetzt, womit sie als eindeutig gultig erklart sind. 

5. In einer spater folgenden Busprozedur sendet 
der ubergeordnete Busteilnehmer dem bzw. den 
untergeordneten Busteilnehmern seine eingefrore- 
nen Feinzeiten zusammen mit der Grobzeit Damit 
ist zugleich die Funktion "Obertragung der Echt- 
zeit" erfullt 

6. Die untergeordneten Busteilnehmer berechnen 
jeweils aus der iibertragenen Uhrzeit und ihrer ei- 
genen (eingefrorenen) Zeit die Differenz ( = Regel- 
abweichung fur die eigene Uhr) und regeln ihre 
Uhren ein oder stellen sie neu, wenn die Regelab- 
weichung mehrmals hintereinander unzulassig 
groB (asynchron) war. 

Diese Prozedur muB nicht sofort durchgefiihrt wer- 
den und kann in Abhangigkeit von der Programmlauf- 
zeit optimal aufgerufen werden. 

Erfolgt die Synchronisation der Echtzeituhren fiber 
einen separaten Takt, dann wird dieser Takt den Prozes- 
soren, die ihre Echtzeituhr damit synchronisieren sollen, 
als Interrupt-Auslosesignal zugefiihrt. 

Die Taktfrequenz betragt vorzugsweise genau ein 
Hertz (Sekundentakt). Der Beginn jeder neuen Sekunde 
wird durch die aktive Taktflanke angezeigt (0-1-Uber- 
gang> 

Es ist von Vorteil, wenn bei beiden in Frage kommen- 
den Synchronisationsverfahren moglichst mit denselben 
Softwareroutinen gearbeitet werden kann, deshalb wird 
eine Prozedur angewendet, die weitgehende Uberein- 
stimmung mit dem oben angegebenen Synchronisa- 
tionsverfahren aufweist. Der wesentliche Unterschied 
besteht darin, daB anstelle einer ereignisgesteuerten 
Routine eine zeitabhangig gesteuerte Routine (Inter- 
rupt-Sekundentaktroutine) durch den Sekundentakt 
aufgerufen wird. In dieser Routine wird fur die Feinzeit 
(die fiber den Bus empfangen wird) ein sekundentaktge- 
rechter Ersatz generiert. 

In der Initialisierungsphase werden zunachst alle Va- 
riablen mit definierten Werten vorbesetzt. Das System 
der Echtzeitverteilung sorgt dann dafiir, daB nach einer 
Hochlaufzeit alle Uhren synchronisiert sind und mit der 
geforderten Genauigkeit "gehen". Alle Zustande wer- 
den fiber Flags angezeigt 

Die Erfindung im folgenden anhand von in einer 
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Zeichnung dargestellten Ausfiihrungsbeispielen naher 
beschrieben, aus denen sich weitere Einzelheiten, Merk- 
male und Vorteile ergeben. Eszeigt 

Fig. 1 ein Schaltbild eiher Anordnung mit einer Zen- 
tralen, die eine zentrale Echtzeituhr enthalt, und mit der 
Zentralen verbundene Teilnehmer, die jeweils Echtzeit- 
uhren enthalten, 

Fig. 2 ein Ablaufdiagramm filr ein Hauptprogramm in 
einem Teilnehmer, der eine Software-Echtzeituhr und 
einen Hardware-Tuner enthalt. 

Fig. 3 ein Ablaufdiagramm der Aktualisierung der 
Uhrzeit in einem Teilnehmer, 

Fig. 4 ein Ablaufdiagramm der Feststellung des Zahl- 
standes des Hardware-Timers in einem Teilnehmer, 

Fig. 5 ein Ablaufdiagramm der Eingabe eines neuen 
Zahlstands in den Hardware-Timer, 

Fig. 6 ein Ablaufdiagramm des Takts der Software- 
Echtzeituhr, 

Fig. 7 ein Ablaufdiagramm fur die Generierung von 
Millisekundentakten, 

Fig. 8 ein Ablaufdiagramm fur die Bearbeitung des 
Millisekundentakts, 

Fig. 9 ein Ablaufdiagramm eines einen externen Se- 
kundentakt zugeordneten Interrupts, 

Fig. 10 ein Ablaufdiagramm eines einen Empfangs- 
takt zugeordneten Interrupts, 

Fig. 1 1 ein Ablaufdiagramm eines einem Uhrzeitsyn- 
chrontakt zugeordneten Interrupts, 

Fig. 12 ein Ablaufdiagramm eines einem Primaruhr- 
Synchrontakt zugeordneten Interrupts. 

In einer Station 4 bzw. ProzeOleitsystem ist als Zen- 
tralteil eine Stationseinheit 1 vorgesehen. Diese enthalt 
als Steuereinheit ein Mehrrechner- System, z. B. mit par- 
allelem Bus. 
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tion an die Busteilnehmer 2, 3, deren Echtzeituhr zu 
synchronisieren ist Diese Meldung kann alle Busteil- 
nehmer gleichzeitig synchronisieren. In folgenden Mel- 
dungen wird dann die "eingefrorene" Uhrzeit des Echt- 
zeitverteilers 12 zu den anderen Bus-Teilnehmern iiber- 
tragen. 

Der zentrale Echtzeitverteiler 12 ist auf einer Bau- 
gruppe realisiert Von hier aus werden alle anderen Uh- 
ren in der Stationseinheit 1 uber den Systembus 11 ge- 
stellt und synchronisiert 

Der zentrale Echtzeitverteiler fiihrt hierzu eine Echt- 
zeituhr wie alle anderen Bus-Teilnehmer. 

Im Unterschied zu den anderen Uhren wird diese 
aber nicht von einem iibergeordneten Echtzeitverteiler 
und synchronisiert Das genaue Verfahren der Uhrzeit- 
einstellung und -synchronisation ist abhangig von der 
verwendeten Zentraluhr. 

Zentraluhren 

In jeder Stationseinheit 1 gibt es einen zentralen 
Echtzeitverteiler 12, der eine eigehe Echtzeituhr fiihrt 
und die Echtzeit Uber den Systembus 11 an die anderen 
Echtzeituhren der Stationseinheit verteilt 

Der zentrale Echtzeitverteiler selbst erhalt Uhrzeit 
und "Synchronisierimpulse" von der Zentraluhr 7. 

Die Zentraluhr 7 ist normalerweise Teil der Stations- 
einheit 1 und kann verschieden aufgebaut sein. 

Nachfolgend werden die verschiedenen Verfahren 
einzeln erlautert 

Vorzugsweise empfangt eine Funkuhr den Zeit- und 
Nprmalfrequenzsender DCF77 und stellt Uhrzeit und 
Datum uber verschiedene Schnittstellen zur Verfiigung. 
Werden die Schnittstellen durch die Funkuhr aktiviert. 



Teilnehmer 2, 3 am Systembus 11 sind Baugruppen, 35 dann werden die Schnittstellen- Ereignisse uhrzeitsyn- 



die je eine multimasterfahige Rechnerkarte darstellen. 
Jede Rechnerkarte fiihrt eine Echtzeituhr 5, 6. 

Eine Rechnerkarte der Stationseinheit 1 enthalt zu- 
satzlich die Software eines zentralen Echtzeitverteilers 
12. Diese Baugruppe wird von einer Zentraluhr 7 der 
Station 4 aus mit der Echtzeit versorgt Von hier aus 
wird die Echtzeit zu den Uhren der einzelnen Rechner- 
karten uber den Systembus 11 "verteilt". 

Die Weiterverteilung der Echtzeit geschieht von der 
Stationseinheit 1 aus uber die seriellen Bus-Systeme, 
von denen ein Bus 8 dargestellt ist. Dabei wird ein Anla- 
genbus normalerweise durch eine serielle Schnittstelle 
einer Baugruppe realisiert Falls die notwendigen 
Schnittstellen auf der Baugruppe nicht zur Verfiigung 
stehen und durch Zusatzmodule realisiert werden, die 
normalerweise ebenfalls einen eigenen Mirkoprozessor 
beinhalten, miissen auf diesen ebenfalls eigene Echtzeit- 
uhren gefuhrt werden. 

Als Hardware-Timer 9, 10 wird jeweils der Timer 
eines Prozessors verwendet Die Timer konnen sowohl 
prozessorintern als auch extern Timerereignisse (z. B. 
Timer-Uberlauf) als Interrupt zum Prozessor melden. 

Die Verteilung von Echtzeit uber den Systembus 11 
erfolgt vom zentralen Echtzeitverteiler 12 aus. Dieser ist 
auf einer Rechnerkarte realisiert. Von hier aus wird die 
Uhrzeit uber den Systembus 11 zu alien anderen Teil- 
nehmern 2, 3 iibertragen und synchronisiert. 

Alle beteiligten Busteilnehmer 2, 3 fuhren ihre eigene 
Echtzeituhr. 

Zur Durchfiihrung der Obertragung und Synchroni- 
sation der Echtzeit uber den Systembus 11 bewirbt sich 
der zentrale Echtzeitverteiler 12 urn die Bushoheit Er 
sendet zunachst eine Meldung zur Uhrzeitsynchronisa- 



chron ausgeldst Die absolute Wiederholgenauigkeit b 
tragt hierbei 20 Millisekunden (abhangig von der Emp- 
fangsfeldstarke) bei einem Kurzzeitjitter von einer Mil- 
lisekunde. 

40 Die Funkuhr 7 sendet selbstandig alle Sekunden Uhr- 
zeit und Datum uber ihre serielle Schnittstelle zum 
Echtzeitverteiler 12. J 

Fur den zentralen Echtzeitverteiler 12 bedeutet dies, 
dafi alle Sekunden durch den Sekundentakt einen Inter- 
45 rupt ausgeldst wird. Darauf folgt die komplette Ober- 
tragung der Uhrzeit 

Der jeweilige Systembus-Teilnehmer 2, 3 und eventu- 
ell vorhandene Zusatzmodul n sind uber eine gemeinsa- 
me Schnittstelle miteinander gekoppelt. Alle Module 
enthalten je eine eigene Echtzeituhr. Dabei wird die Uhr 
auf dem Zusatzmodul von der (iibergeordneten) Uhr 
uber die Schnittstelle gestellt und synchronisiert. Auch 
hier wird grundsatzlich das unten noch naher erlauterte 
Obertragungsverfahren angewendet 

Lediglich die "Synchronisation iiber die Datenschnitt- 
stelle" wird abgeandert, da es kein Hardware-Schnitt- 
stellenereignis gibt, das auf beiden Seiten der Schnitt- 
stelle einen Interrupt auslost Hier lost lediglich ein Teil- 
nehmer 2 bzw. 3 auf einer Seite der Schnittstelle einen 
Interrupt beim Teilnehmer auf der anderen Seite der 
Schnittstelle aus. Als Ersatz fur den Interrupt der auftre- 
tenden Seite wird dort unmittelbar nach deni Auslosen 
(des Interrupts zur anderen Seite) eine Internipt-Ersatz- 
Routine aufgerufen, also so getan, als ware ein Interrupt 
65 der Schnittstellenprozedur ausgeldst worden Die Rich- 
tung, in der dieser Vorgang uber die Schnittstelle ab- 
lauft ist prinzipiell beliebig, sollte jedoch mdglichst der 
Systemhierarchie entsprechen. 
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Die Verteilung der Echtzeit uber den Anlagenbus 8 
erfolgt vom Teilnehmer 2 oder 3 aus. 

Alle beteiligten Busteilnehmer (Master und Slaves) 
fiihren ihre eigene Echtzeituhr. 

Zur Durchfiihrung der Uhrzeitilbertragung und -syn- 
chronisation sendet der Master zunachst ein Tele- 
gramm, das bei den aktiven Bus-Teilnehmern einen In- 
terrupt ausldst. 

Spater wird vom Master die "eingefrorene" Zeit zu 
dem Slave ubertragen. 

Die gcnaue Zeitverschiebung zwischen dem Interrupt 
des Masters und dem Interrupt des Slaves wird einmalig 
experimentell ermittelt. 

Die Echtzeit wird der Feldeinheit uber den Anlagen- 
bus 8 zugefiihrt Auch die Synchronisation der Uhrzeit 
in der Feldeinheit erfolgt iiber den Anlagenbus. 

In den Teilnehmer 2, 3 lauft jeweils ein Hauptpro- 
gramm ab, das eine Software-Uhr enthalt In Fig. 2 ist 
ein Ablaufdiagramm in Verbindung mit der Software- 
Uhr dargestellt. 

Nach dem Start werden die zu steuernden Uhren in 
einem Schritt 13 initalisiert Danach wird in eine Haupt- 
programmschleife 14 eingetreten, die folgende Pro- 
grammteile enthalt: Echtzeit von extern iibernehmen, 
Ausgabe der Uhrzeit, SYNC- Interrupt Disable bzw. 
SYNC-INTERRUPT ENABLE, Disable bzw. enable 
speziellen Interrupt und disable bzw. enable generellen 
Interrupt. Wenn nach dem Durchlaufen der Hauptpro- 
grammschleife noch Programmzeit vorhanden ist, wird 
in einem Programmteil 15 die Echtzeituhr korrigiert 
Ansonsten wird die Hauptprogrammschleife wieder- 
holt. Verbleibt nach der Korrektur der Uhr noch Zeit, 
wird die Echtzeituhr in einem Programmteil 16, das in 
Fig. 3 dargestellt ist 

Das Programmteil 16 enthalt die Programmteile 17, 
18, 19, 20 jeweils fiir Interrupt disable, Hardware-Timer 
lesen, Uhrzeit neu berechnen und Interrupt enable. 

Die Uhrzeitfuhrung durch Hardware-Timer lesen, 
geht aus Fig. 4 hervor. Dieses Unterprogramm enthalt 
die Teile Interrupt disable, Timer Input 21, die Abfrage 
nach dem Uberlauf des Timers nach dem letzten Einle- 
sen, die Korrektur 22 des Zahlerstands bei einem Uber- 
lauf und dem Schnitt Interrupt enable. Der Aufbau des 
Unter-Programms 21 ist in Fig. 5 dargestellt. Das Un- 
terprogramm beinhaltet die Erstellung einer Kopic des 
Hardware-Timers und, wenn die einzelnen Zahlerworte 
synchron gelesen werden miissen, die temporare Spei- 
cherung der Worter. Es wird der Stand des Hardware- 
Timers, der der letzten aktuellen Software-Uhrzeit ent- 
spricht, bereitgehalten. Die Aktualisierung des Softwa- 
re-Uhr-Takts ist in Fig. 6 dargestellt. Diese Aktualisie- 
rung beinhaltet folgende Unterprogramme: Millisekun- 
dengenerierung 23, Millisekundentaktbearbeitung 24, 
Minutentaktbearbeitung 25, Stundentaktbearbeitung 
26, Tagestaktbearbeitung 27, Monatstaktbearbeitung 
28, Jahrestaktbearbeitung 29 und Uhrzustandtest 30. 

Das Unterprogramm 23 setzt zunachst den Millise- 
kundentakt auf null und pruft danach, ob der Hardware- 
Timer um 1 ms weitergezahlt hat. Wenn dies der Fall ist, 
wird die Hardware-Timer-Nachfuhrung um 1 ms erhoht 
und anschlieBend 1 ms fur die Software-Uhr registriert, 
bevor die Prufung wiederholt wird. Hat der Hardware- 
Timer nicht um 1 ms weitergezahlt, dann wird der Ti- 
mer-Rest mit dem Stand der Software-Uhr verrechnet. 

Die Verarbeitung der Millisekundentakte ist in Fig. 8 
dargestellt. Nach dem in Fig. 8 dargestellten Verfahren 
werden Minutentakte aus Millisekundentakte erzeugt 
Die Verarbeitung der Minutentakte, Stundentakte, Ta- 



gestakte, Monatstakte und Jahrestakte erfolgt entspre- 
chend und ist nicht naher dargestellt 

Im System wird durch die getrennte Ubertragung der 
Echtzeit zu den Teilnehmern und der Synchronisations- 
5 information eine Verminderung der Belegung der Uber- 
tragungskanale durch die Echtzeitverteilung erreicht. 
Die Echtzeit wird an alien Schnittstellen mit dem glei- 
chen Datenformat ubertragen. Das Datenformat ist da- 
her unabhangig von der Art der Synchronisation der 

to Echtzeituhren. Die Echtzeit wird blockweise uber die 
jeweilige Schnittstelle und in einem Stuck ubertragen, 
wobei die gleichzeitige Uhrverstellung verriegelt wird 
Die Echtzeitkorrektur im jeweiligen Teilnehmer be- 
ginnt mit einem Aufruf durch die Uhrzeit- Obergabe. 

15 Danach wird die berechnete Uhrzeit mit der Sollzeit 
verglichen. Die Uhrzeit ist unterteilt in eine Grobz it 
und eine Feinzeit. Es wird gepriift, ob die berechnete 
Uhrzeit innerhalb zulassiger Toleranzen mit der iiber- 
tragenen Uhrzeit ubereinstimmt. Falls dies nicht zutrifft, 

20 wird die Zeit in der Echtzeituhr des jeweiligen Teilneh- 
mers korrigiert. 

Vorzugsweise werden die Echtzeituhren Uber die vor- 
handenen Schnittstellen synchronisiert Fiir die Schnitt- 
stellen wird eine Synchronisationsprozedur definiert. 

25 Alle verwendeten Schnittstellen bieten die Moglichkeit, 
durch bestimmte Schnittstellenereignisse (insbesondere 
"Ubertragung beendet") einen Interrupt zu dem Prozes- 
sor, der die Uhrzeit fuhrt, auszulosen. 

Fiir die Synchronisierung wird eine spezielle Bus-Pro- 

30 zedur (Obertragung vom Master zum Slave) mit einer 
vorgebbaren Kennung SYNC gestartet Diese Prozedur 
kann ein Aufruf an alle sein. Die SYNC-Prozedur lost 
bei alien beteiligten Busteilnehmern (auch beim Master) 
einen Interrupt aus. Fiir die Interrupt-Ausldsung kann 

35 ein externer Sekundentakt, ein Empfangstakt, ein Uhr- 
zeitsynchrontakt oder ein Primaruhr-Synchrontakt vor- 
gesehen sein. Je nach dem fur die Interruptauslosung 
bestimmten Takt ergeben sich verschiedene Verfah- 
rensschritte. Nach der in Fig. 9 gezeigten, durch einen 

40 externen Sekundentakt bewirkten Synchronisierung 
schiieBt sich an den Interrupt-Schritt ein Unterpro- 
gramm 31 "Uhrzeit bearbeiten" an, nach dessen Ende in 
einem nachfolgenden Schritt 32 ein Flag gesetzt wird, 
das einen Synchrontakt als "Sekundentakt" kennzeich- 

45 net. Danach wird die Soll-Feinzeit anhand des Sekun- 
dentakts berechnet. AnschlieBend wird die Differenz 
zwischen dem Zahlerstand und dem Rest null gesetzt, 
woraus sich eine neue Feinzeit ergibt. 
Bei einem Interrupt mit Hilfe eines Empfangstakts 

so wird das in Fig. 10 dargestellte Verfahren durchlaufen. 
Es folgt auf den Interrupt Schritt wiederum das Unter- 
programm 31, dem sich ein Schritt 35 anschlieBt, in dem 
ein Flag den Synchrontakt als Empfangstakt kennzeich- 
net. Das in Fig. 1 1 dargestellte Unterprogramm 31 ent- 

55 halt einen Interrupt-Schritt, der unmittelbar durch einen 
Uhrzeitsynchrontakt ausgelost werden kann. An diesen 
Schritt schiieBt sich das Unterprogramm 16, Uhrzeitak- 
tualisieren an, auf das ein Unterprogramm 35 "Feinzeit 
merken" folgt. Danach wird in einem Schritt 36 der Syn- 

60 chrontakt gezahlt In einem Schritt 37 wird ein Flag 
gesetzt, wenn die Kennung SYNC wahrend einer Ihter- 
ruptsperre erzeugt wurde. 

Wenn ein Interrupt durch einen Primaruhr-Synchron- 
takt erzeugt wird, wie er z. B. von einem Empfanger 

65 eines Zeitsenders erzeugt wird, dann wird auf den Inter- 
rupt-Schritt wiederum die Uhrzeit durch das Unterpro- 
gramm 16 aktualisiert. Danach folgt das Unterpro- 
gramm 36, nach dessen Ende ein Interrupt-Request 
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durchgefuhrt wird, der sich auf eine Interruptsperre be- 
zieht. Wenn keine Interruptsperre beim Eintreten des 
SYNC-Ereignisses eintritt, wird der Interrupt zu einer 
Zieladresse zugeordnet, wonach die Feinzeit und die 
Grobzeit fur die Ausgabe zur Verfiigung stehen. Bei 5 
einer Interruptsperre wird die Uhrzeit erst nach der 
Interrupt-Freigabe eingefroren, bevor die weiteren 
oben erwahnten Schritte folgen. 

In einer anschlieBenden Busprozedur sendet der Ma- 
ster dem oder den Slaves seine eingefrorenen Feinzei- 10 
ten zusammen mit der Grobzeit Damit ist die Ubertra- 
gung der Echtzeit beendet 

Jeder Slave wird vorzugsweise mindestens mehrmals 
pro Minute synchronisiert Die Slaves berechnen aus 
der iibertragenen Uhrzeit und ihrer eigenen eingefrore- 15 
nen Zeit die Zeitdifferenz fur die eigene Echtuhr und 
regeln ihre Uhren nach bzw. stellen sie neu ein. Wenn 
die Regelabweichung mehrmals nacheinander unzulas- 
sig groB war, wird eine Testprozedur zur Fehlersuche 
angefuhrt Die Testprozedur muB nicht sofort durchge- 20 
fiihrt werden, sondern kann unter Beriicksichtigung der 
Programmlaufzeit optimal aufgerufen werden. 

In der Initialisierungsphase werden alle Variablen mit 
definierten Werten besetzt. Die Echtzeitverteilung 
sorgt dafiir, daB nach einer Hochlaufzeit alle Echtzeit- 25 
uhren synchron laufen. Alle Zustande werden durch 
Flags angezeigt. 

Patentanspriiche 

30 

1. ProzeBsteuersystem mit einer Reihe von Teilneh- 
mern, die jeweils Hardware-Zeitgeber enthalten 
und durch Bussysteme miteinander verbunden sind, 
iiber die Informationen nach vorgegebenen 
Schnittstellenprozeduren iibertragen werden, mit 35 
denen Interrupts in den Teilnehmern ausldsbar 
sind, dadurch gekennzeichnet, daB in einem Teil- 
nehmer eines Busses (1, 2, 3) fur die Echtzeit eine 
Zentraluhr (7) vorgesehen ist, daB in den anderen 
Busteilnehmern gegebenenfalls Echtzeituhren (5, 6) 40 
vorgesehen sind, die jeweils eine von einem Prozes- 
sor gefuhrte Software-Uhr enthalten, deren Wei- 
terschahung vom Prozessor durch Zugriff auf einen 
Hardware-Zeitgeber vorgenommen wird, und daB 
zur Synchronisierung der Uhren dieser Teilnehmer 45 
(2, 3) eine Synchronisationsprozedur vorgesehen 
ist durch die jeweils die Echtzeit der Zentraluhr (7) 
festgehalten und in einem definierten Zeitabstand 
hierzu in wenigstens einem Teilnehmer (2, 3) ein 
Interrupt ausgelost wird, durch dessen Auftreten jo 
die im Teilnehmer vorhandene Echtzeit ebenfalls 
festgehalten und mit der vom Echtzeitverteiler in 
das Datenformat der Schnittstelle umgesetzten und 
zum Teilnehmer iibertragenen Echtzeit der Zen- 
traluhr zum Nachstellen der Echtzeituhr im Teil- 55 
nehmer (2, 3) verwendet wird. 

2. ProzeBsteuersystem nach Anspruch 1, dadurch 
gekennzeichnet daB die Hardware-Zeitgeber in 
den Teilnehmern (2, 3) frei laufend und somit auch 
fur andere Zwecke nutzbar oder programmierbar 60 
sind und daB jeweils aus der Zahlstandsdifferenz 
des Hardware-Zeitgebers das Wciterschalten der 
Software-Uhr bestimmt wird. 

3. ProzeBsteuersystem nach Anspruch 1 oder 2, da- 
durch gekennzeichnet daB der Hardware-Zeitge- 65 
ber mindestens ein aus einer Taktquelle gespeister, 
frei laufender Dualteiler ist. 

4. ProzeBsteuersystem nach einem der vorherge- 
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henden Anspruche, dadurch gekennzeichnet, daB 
die Taktquelle nur ine geringe Langzeitstabilitat 
haben muB. 

5. ProzeBsteuersystem nach einem der vorherge- 
henden Anspruche, dadurch gekennzeichnet, daB 
der Uberlauf des jeweiligen Hardware-Zeitgebers 
(9, 10) im Teilnehmer (2, 3) die Berechnung der 
Echtzeit ausldst oder einen Software-Uberlaufzah- 
ler beaufschlagt dessen Inhalt bei spater durchge- 
fiihrter Berechnung berucksichtigt wird, oder daB 
der Hardware-Zeitgeber durch den Prozessor in so 
kurzen Zeitabstanden gelesen wird, daB der Uber- 
lauf aufgrund der Zeitabstande sicher erkannt wird. 

6. ProzeBsteuersystem nach einem der vorherge- 
henden Anspruche, dadurch gekennzeichnet, daB in 
jedem iibergeordneten Busteilnehmer durch ein n 
Interrupt das Festhalten der aktuellen Uhrzeit syn- 
chronisiert und die festgehaltene Uhrzeit zu unter- 
geordneten Einheiten iibertragen wird und in die- 
sen jeweils mit einer dort durch einen entsprechen- 
den Interrupt desselben Busereignisses festgehalte- 
nen Uhrzeit verglichen Wird und daB die Differenz 
zur Korrektur der Ganggeschwindigkeit der Echt- 
zeituhr in der untergeordneten Einheit verwendet 
wird. 
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